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METHOD AND APPARATUS FOR FACILITATING ELECTRONIC ACQUISITION 



AND MAINTENANCE OF GOODS AND SERVICES VIA THE INTERNET 



CROSS-REFERENCE TO RELATED APPLICATIONS 

Not applicable. 

BACKGROUND OF THE INVENTION 

Field of Invention 

[0001] This invention relates to a method and apparatus for electronic acquisition and 
maintenance of goods and services via the Internet. More particularly, the present invention 
relates to a method and apparatus for customer acquisition and maintenance of goods and 
services from a plurality of service providers networked to an order facilitation service. 
Background of the Invention 

[0002] Many people recognize the benefits of "one-stop shopping", such as may be found at a 
convenience store or shopping mall. The benefits may include reduced travel and improved ease 
of comparison. Merchants that offer one-stop shopping may consequently provide enhanced 
customer satisfaction and acquire more customers relative to merchants that do not offer one-stop 
shopping. Despite the recognized benefits of one-stop shopping, there exist circumstances where 
it is not offered. One such circumstance is services for new tenants. 

[0003] Tenants of various types of properties, whether business or residential, whether multi- 
business, multi-family, single-business or single-family, from time to time, relocate or move 
from one property to another. Such relocations may involve worldwide moves, interstate moves, 
intrastate moves or local moves. Regardless of the geographical bounds of the move, upon 
relocating tenants frequently engage in a substantial effort to acquire utility services such as 
electricity and telephone services. The foregoing effort is further increased by the fact that 
tenants must also disconnect services and utilities at their previous address. Tenants must also 
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contact many financial institutions, such as banks, credit card issuers and investment institutions, 
to inform them regarding their change of address. Typically, tenants contact each service 
provider individually to arrange for acquisition of services. Generally, this effort involves 
numerous telephone calls with substantial wait times and lengthy interviews with representatives 
5 of each service provider. Furthermore, many service providers are unavailable during evenings, 
weekends and holidays. 

[0004] There has been very limited "automated" help available to relocating tenants. Some 
companies offer a service whereby tenants can register all of their credit cards with such 
companies. When a tenant moves, he or she contacts the company with whom the tenant is 
!S 10 registered, and the company will contact all card issuers of the tenant and inform them of the 
q tenant's change of address. While such a service provides some assistance to a relocating tenant, 

S ; s 

In it is limited to address changes and furthermore, it is limited to a particular type of service 

y 1 provider, namely credit card issuers or financial institutions. There are also some online services, 

la such as move.com, that provide limited assistance. Typically, the extent of the assistance 

■M 15 involves providing a link to the service provider's Internet web site or sending a very basic 
^ communication, such as email, to the service provider to inform them the tenant has moved or 

that the tenant needs a particular utility. At that point, each service provider makes contact with 
the tenant, which generally, takes the form of traditional contact via a telephone call to the tenant. 
[0005] Similarly, tenants routinely acquire various goods and services that vary with the 
20 property type. For example, a business tenant usually needs office-supply on a regular basis and a 
residential tenant may need dry cleaning services. Regardless of the product or service needed, 
tenants frequently need easy access to such products and services. Typically, tenants contact each 
service provider individually to arrange for acquisition of the goods and services. Furthermore, 
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there is no easy way to shop and compare such goods and services and be able to automatically 
and immediately place orders with the selected service provider, all from one common place. 
Tenants may have to contact numerous service providers individually, take notes, compare them 
later and finally call back the selected provider and place an order. While some online services 
5 enable comparison of products and services, such online merchants do not provide integration of 
the acquisition process in the manner and with the efficiencies of the present invention. 
[0006] The above-described prior art methods and systems for acquisition and maintenance of 
goods and services by property tenants are inefficient. Accordingly, it would be desirable to 
provide a method and system which provides the benefits of one stop shopping in a uniform, 

10 integrated structure that eliminates inefficiencies of the prior art methods. 

BRIEF SUMMARY OF THE INVENTION 
[0007] The present invention solves the problems faced by the prior art methods and systems. 
The present invention provides a method and apparatus for acquisition and maintenance via the 
Internet of goods and services from multiple service providers in a uniform, automated and 

15 integrated manner. In the preferred embodiment of the present invention, property tenants, such 
as residents of single or multi-family properties, may connect and disconnect utilities and/or 
purchase other goods and services electronically via the Internet from various service providers 
prior to moving in, upon moving in, and after moving in to the property. The utility and 
advantages of the present invention make it a highly desirable and commercially practicable 

20 mechanism for easy, quick and efficient acquisition and maintenance of goods and services by 
property tenants from a plurality of service providers. 

[0008] The present invention particularly contemplates an online service for facilitating 
provision of services to customers. The online service preferably comprises a network, and at 
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least one computer coupled to the network. The computer interacts with service provider, brand 
partners, and customers, via the network to maintain a database of service provider accounts, 
brand partner accounts, and customer accounts. The service providers enter service products in 
the database for access by customers, the brand partners enter customization elements in the 
5 database, and customers enter personal information in the database. The computer presents a list 
of service products to a customer customized in accordance with customization elements of a 
brand partner associated with the customer, and customized in accordance with an address 
associated with the customer. The customer may then provide order information to the computer, 
which then directs the order information to the appropriate service providers and updates the 
;~ 10 customer's account to reflect the orders. The computer may further receive communications from 
□ the service providers regarding specific orders, and update the customer account database to 

IH reflect the communications. 

as 

" s' 

y - [0009] The present invention further contemplates a method of selling a service product, 

|7t comprising: (a) generating in multiple service categories representations of multiple service 

•.q 15 products; (b) providing an interactive display of one or more of the representations within a 
M service category to a customer; and (c) displaying an order form in response to customer 

actuation of an order icon. The service product representation includes a plan component, a 
package component, and a feature component. The interactive display includes selection icons 
adjacent corresponding plans, packages, and features specified by the service product 
20 representations, and includes an order icon for each displayed service product representation. 

[0010] The present invention further contemplates systems and methods that allow for 
straightforward, yet flexible, definition of service product markets; advantageous status 
designations for market offerings; flexible start date restriction rules; context sensitive 
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information request forms, dynamic price determination on interactive comparison forms; 
flexible restriction rules for selection combinations of plans, packages, and features; creation of 
customized data elements; a powerfully advantageous ordering process; a discontinuation 
process; an inter-dependent order resolution feature; a hierarchical customization scheme; and/or 
centralized two-way communication between customers and service providers. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0011] A better understanding of the present invention can be obtained when the following 
detailed description of the preferred embodiment is considered in conjunction with the following 
drawings: 

[0012] Figure 1 is a system block diagram of a preferred embodiment showing the relationships 
and the flow of information between customers, brand partners, service providers and the 
facilitation provider. 

[0013] Figure 2 is a block diagram illustrating the various activities of brand partners with 
respect to the facilitation provider. 

[0014] i Figure 3 is a block diagram illustrating the configuration relationships of brand partners. 
[0015] Figures 4 and 5 illustrate the data elements and their relationships in a data type 
definition format as used in the preferred embodiment relating to brand partners. 
[0016] Figure 6 illustrates the data elements and their relationships in a data type definition 
format as used in the preferred embodiment relating to customers. 

[0017] Figure 7 is a block diagram illustrating the various activities of customers in acquiring 
and maintaining services via the facilitation provider. 

[0018] Figure 8 illustrates the interface customers use to acquire access to the facilitation 
provider. 



[0019] Figure 9 illustrates the selection of services and service providers by customers. 
[0020] Figure 10 illustrates the selection of plans in service offerings by customers. 
[0021] Figure 11 illustrates the comparison and selection of plans, packages and features in 
service offerings by customers. 

[0022] Figure 12 illustrates the recap of selected plans, packages and features by customers and 

the entry of related additional information by customers. 

[0023] Figure 13 illustrates the disconnection of services by customers. 

[0024] Figure 14 illustrates the customers' profile information. 

[0025] Figure 1 5 illustrates the interface customers use to update general information. 

[0026] Figures 16 and 17 illustrate a sample report showing a customer's account summary. 

[0027] Figure 18 is a block diagram illustrating the various activities of service providers with 

respect to the facilitation provider. 

> 

[0028] Figures 19(a) and 19(b) show illustrative interface screens that may be used to define 
markets for service provider offerings. 

[0029] Fi|gure 20 illustrates the data elements and their relationships in a data type definition 
format as used in the preferred embodiment relating to customers. 

[0030] Figure 21 illustrates a sample email with an order URL notifying service provider that 
an order has been received from a customer. 

[0031] Figure 22 illustrates a sample order displayed after service provider clicks on the URL 
link in email order notification. 

[0032] Figure 23 illustrates a sample response screen used by a service provider to respond to a 
customer's service order. 

[0033] Figure 24 shows an illustrative order communication process. 



[0034] Figure 25 shows a block diagram of a preferred communicator application embodiment. 
[0035] Figure 26 illustrates the process of the real-time integration communication method 
between the facilitation provider and service providers' legacy systems. 

[0036] Figures 27(a) and 27(b) are flowcharts illustrating the process used by service providers 
to request orders from the facilitation provider, parse the orders and the XML mapping to the 
service provider's database or specified file format. 

[0037] Figure 28 is a flowchart illustrating the use of Java class by service providers for 
creating responses to order requests. 

[0038] Figure 29 is a flowchart of the communicator update process. 
[0039] Figure 30 is a flowchart of the order handling aspect of a preferred embodiment. 
[0040] Figure 31 is a flowchart of the service provider market determination aspect of a 
preferred embodiment. 

[0041] Figure 32 is a diagrammatic illustration of a data structure used to represent offerings. 

[0042] Figure 33 further illustrates aspects of the preferred data structure. 

[0043] Figure 34 shows a detailed architecture of one communicator embodiment. 

[0044] Figure 35 shows a class diagram of the communicator's logging component. 

[0045] Figure 36 shows a class diagram of the communicator's transform component. 

[0046] While the invention is susceptible to various modifications and alternative forms, 

specific embodiments thereof are shown by way of example in the drawings and will herein be 

described in detail. It should be understood, however, that the drawings and detailed description 

thereto are not intended to limit the invention to the particular form disclosed, but on the 

contrary, the intention is to cover all modifications, equivalents and alternatives falling within the 

spirit and scope of the present invention as defined by the appended claims. 



DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT 
[0047] Turning now to the figures, Figure 1 shows a block diagram of a preferred embodiment. 
Customers 110 may establish an acquaintance or business relationship with a brand partner 120. 
Brand partner 120 is one of many persons or commercial entities that employ the services of 
5 facilitation provider 140, and brand partner 120 informs customers - 1 1 0 of the facilitation 
provider's availability for their use in securing the offerings of service providers 130. 
[0048] As an example, consider the scenario in which new residents (customers 1 1 0) enter into 
a lease agreement with an apartment complex (brand provider 120). The residents will typically 
need to establish various utilities and services (e.g., water, gas, electric, local and long distance 
;^ 10 telephone, mobile telephone, cable, mail delivery) at their new address, and discontinue those 
R utilities and services at their previous address. The apartment complex can establish an account 

iJl for the residents with facilitation provider 140, whereby the residents can establish and 

^ i discontinue their utilities and services in one convenient setting. 

;?I [0049] The facilitation provider 140 takes any necessary information from the customers 110 

:S 15 and electronically communicates orders to the appropriate service providers 130. The service 
j=* providers 130 enter the orders into their normal order stream and establish, modify, or 

discontinue their services to the customers 110. The format and architecture of the system is 
designed to sharply reduce the effort required by the customers 110, significantly reduce the 
resources required by the service providers 130, and improve the marketability of the brand 
20 provider 120. 

[0050] In the example given above, residents can secure their necessary utilities and services in 
less than ten minutes, as opposed to the normal requirement of two to four hours for contacting 
each service provider individually, enduring the hold interval, and repeatedly providing much of 
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the same information to a customer service representative. Service providers typically can 
substantially reduce the effort expended by customer representatives because the order 
information is automatically provided in a standard format and representatives do not have to 
hand-key the information. (Indeed, service providers who choose to use the communicator 
5 application can entirely eliminate intervention by customer service representatives.) The 
apartment complex can advertise the facilitation service as one of their amenities, because it 
permits easy acquisition and maintenance of available services by their residents. Further, the 
available services have an incentive to competitively price their offerings for residents because 
the facilitation service provides for easy comparison of available service provider offerings, or 
10 alternatively, the service providers can negotiate with the apartment complex for exclusive access 
to the residents. 

[0051] Figure 1 shows that the service provider 130 may include a marketing department 132, a 
fulfillment department 136, and optionally a communicator application 134. The optional 
communicator application 134 preferably runs on the service provider's internal computer 

15 network to communicate with one or more of the file sources provided by the facilitation 
provider 140. The communicator 134, which is described in greater detail below, can be run 
anywhere (e.g., service provider, facilitation provider, independent third party site) to effectuate 
the transfer of files between the facilitation provider and the service provider. 
[0052] As will be described in more detail below, the communicator 134 retrieves orders 

20 placed by the customers 110, and updates each order with status information and any 
communications that the fulfillment department may wish to send to the customer. The 
communicator 1 34 preferably is a versatile application which can be configured by the marketing 
department 132 and used by the fulfillment department 136 in a variety of ways. The fulfillment 
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department 136 may optionally use software provided by the facilitation provider 130 or may use 
internally customized software to interface with the communicator application 134. As the use of 
the communicator application 134 is optional, the marketing department 132 may alternatively 
configure the facilitation provider 140 to send emails or faxes of orders to the fulfillment 
department 136 if the service provider 130 prefers to handle orders manually. In addition, the 
fulfillment department 136 may use standard web-based software to access the interface 144 via 
the Internet to process orders. 

[0053] The facilitation provider 140 preferably executes a set of applications on a reliable 
computer network. The applications include a customer interface 141, one or more databases 
142, a brand partner interface 143, a service provider interface 144, and a configuration manager 
145. 

[0054] Each of the interfaces 141, 143 and 144, is preferably presented to the corresponding 
users in the form of a sequence of web pages, which the customers 1 10, brand partners 120, and 
marketing department 132 can access via the Internet. Customers 1 10, in particular, may access a 
web page for the brand partner 120 over the Internet that includes a link to the customized 
customer interface 141. Selecting the link causes the customer's web browser (or other web- 
compatible software application) to access the customer interface 141 to communicate with 
database 142. Alternatively, the customers 110 may steer their web-software directly to the 
interface 141. As yet another option, a voice-activated browser may be used by one or more of 
the users to select particular options available via interfaces 141, 143 and/or 144. 
[0055] Brand partners 120 and service providers 130 wishing to take advantage of the 
facilitation provider's services may enter into an engagement agreement with the facilitation 
provider 140. The facilitation provider 140 uses the configuration manager 145 to create 
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accounts for the brand partners and service providers in the database(s) 142. The service 
providers 130 can then access their accounts via service provider interface 144 to specify their 
goods or services. The brand partners 120 can access their accounts via brand partner interface 
143 to create customer accounts. Customers 110 can access their accounts via customer interface 
141. 

[0056] Service providers 130 use interface 144 to setup and register service offerings. As part 
of the setup and registration process for service offerings, service providers 130 provide detailed 
information regarding utilities, products or services that will be offered to customers 110. This 
detailed information may include custom-tailored, mutually exclusive "markets" in which the 
products or services are available. 

[0057] In the present application, the term "service providers" is used in a very broad sense to 
include, without limitation, all entities such as merchants, individuals and businesses, whether 
for profit or not for profit, which can provide or sell any services, utilities, products, goods and 
anything else that may be offered to customers 110. Service providers 130 incorporates the 
foregoing definition. Similarly, the term "service categories" is used in a very broad sense and 
includes, without limitation, any categories of services, utilities, products, goods and anything 
else that may be offered to customers 110 by service providers 130. By way of illustration, 
examples of service categories include local telephone service, long distance telephone service, 
electricity, gas, cable television, satellite television, Internet access services, cleaners, groceries, 
insurance, furniture rental, bottled water, maid service, newspaper and magazine delivery, pet 
food and pet related services, prescription drug services, delivery services, transportation 
services, food services, and anything else that a service provider may provide to customer 110. 
Furthermore, the term "service" itself is used in a very broad sense and includes, without 



limitation, any services, utilities, products, goods and anything else that may be offered to 
customers 1 10 by service providers 130. 

[0058] Brand partners 120 use brand provider interface 143 to customize the customer interface 
141, set up employee accounts, and to set up customer accounts. The customization of customer 
interface 141 includes selecting a color scheme, selecting a banner identifying the brand partner, 
selecting which service categories will be available to their customers 110, and selecting which 
service providers 130 may offer their services to the customers 1 10 under each service category. 
The brand partners may choose to select a logo for display, a marketing image (such as a picture 
of the building where the brand partner is housed), a layout template, and other customization 
elements such as, e.g., color, font, display text, that help create a unique "feel" that the brand 
partners wish to be associated with. As customers 110 enter into relationships with the brand 
partner 120, the brand partners use interface 143 to set up access accounts for the customers. 
Note that the brand partners 120 may set up multiple accounts. For example, property managers 
may wish to set up a different customer interface and selection of services for each of multiple 
apartment complexes under their management. 

[0059] By way of example and without limitation, brand partners may be property managers, 
landlords, real estate agents, universities, the Armed Forces, relocation specialists, movers, web 
portals, search engine sites, other web sites, corporations, and service providers. 
[0060] Customers 110 use interface 141 to select categories of services they desire, to compare 
service providers within those categories, and to place an order for establishment or 
discontinuance of services from selected service providers. Once a customer 110 decides to place 
an order with a service provider 130, facilitation provider 140 sends an electronic notification of 
the order to the service provider. The service provider 130 processes the order and preferably 
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sends an electronic response back to the facilitation provider 140. (Of course, the service 
provider 130 may also contact customer 100 directly via traditional mechanisms, such as a 
telephone, in response to the order.) Customers 110 can access their facilitation provider account 
at will to view the status of their orders and any associated communications received from the 
service providers 1 30. 

[0061] In this manner, customers 110 enter into agreements with service providers 130 to 
receive services, including utilities, and to purchase various goods. As part of the various 
agreements in place between customers 110, brand partners 120, service providers 130 and 
facilitation provider 140, certain financial incentives are in place and accordingly certain 
monetary payments may be made between the foregoing parties. 

[0062] As stated above, brand partners 120 preferably must engage in certain activities before 
customers 110 can access facilitation provider 140 to purchase goods and services offered by 
service providers 130. Referring now to Figure 2, brand partners 120 may set up (or have set up 
for them) various administrative and brand partner accounts 202 on facilitation provider 140. 
Brand partners 120 may also make certain selections 204 to customize customer interfaces 141, 
and may make selections 206 regarding what service categories will be available to customers 
110 and which service providers 130 may offer their services to the customers 110 under each 
service category. Once the foregoing activities have been completed, brand partners 120 may 
then engage in customer registration 208. There are a number of reporting options 210 for brand 
partners 120 to help track and analyze the various transactions and activities. 
[0063] In the preferred embodiment of the present invention, all of the foregoing activities by 
brand partners 120 are performed by accessing computer applications that reside on facilitation 
provider's computer network. However, as one of ordinary skill in the art will appreciate, such 
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applications may be located on a single web server or distributed across different computer 
networks. Further the physical location of the computer executing the applications may vary and 
may be at multiple locations, e.g. at a central location of the facilitation provider and/or at the 
brand partner's site. 

5 [0064] Brand partners 120 may set up administrative and unit brand partner accounts 210. 
Generally, brand partner accounts that are configured as administrative accounts do not engage in 
customer registration activities, whereas brand partner accounts configured as unit accounts do 
engage in customer registration activities, and may also engage in administrative activities. 
Referring now to Figure 3, a root account 302 is created by facilitation provider 140 using 
10 configuration manager 145. The facilitation provider accessing the root account can create 
multiple brand partner accounts 31x. 

[0065] In the exemplary embodiment of Figure 3, the facilitation provider has created two 
administrative accounts 312, 314, and a unit account 316. The brand partner assigned to 
administrative account 314 has in turn created an administrative account 322 and two unit 

15 accounts 324, 326. This might be desirable for a parent company wishing to establish accounts 
for each of its subsidiaries. Each of these subsidiaries may in turn be parent companies wishing 
to create accounts for each of its sub-subsidiaries. In Figure 3, the subsidiary brand partner 
assigned to administrative account 322 has created three unit accounts 332, 334, 336. Employees 
assigned to unit account 334 can register various customer accounts for the customers they serve. 

20 [0066] The foregoing results in an account structure having a tree-like form. Each 
administrative account has some control over the configuration options made available to those 
accounts below it, and may optionally be subjected to restrictions imposed by accounts above it. 
Further, each account reports to the accounts above it. 
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[0067] In the preferred embodiment of the present invention, the foregoing organization of 
brand partners, along with the related data structure which facilitates the foregoing relationships, 
enables higher-level administrative brand partners 31x to set up global rules or limitations which 
are automatically inherited by subordinate administrative and unit brand partners 32x. In the 
hierarchy of relationships between the two types of brand partners, the facilitation provider's 
database is configured as the parent 302 of all administrative and unit brand partners (numbered 
as 312 through 336 in Figure 3). Therefore, the parent account 302 contains all of the rules and 
limitations, which are then filtered down to all administrative and unit brand partners (312-336). 
By way of illustration, the rules and limitations include such things as the master list of all 
service categories and service providers that are available for selection by all brand partners 120. 
[0068] Such rules and limitations preferably govern the manner in which the subordinate 
administrative and unit brand partners (312-336) conduct the business of configuring customer 
interfaces and making goods and services available to customers 110. For example, subordinate 
brand partner accounts 32x are limited to the particular service categories and service providers 
selected by higher- level administrative brand partner 314. Similarly, the selections made by 
administrative brand partner 322 are imposed upon unit brand partners 332, 334 and 336. In this 
manner, and in accordance with the preferred embodiment, each administrative brand partner can 
further filter rules and limitations down to lower-level administrative brand partners and unit 
brand partners. Parent accounts may choose to set up their selections as defaults which can be 
overridden by subordinate accounts. 

[0069] In setting up unit brand partners, brand partners 120 provide certain required data 
elements to facilitation provider 140 regarding the customers (e.g., residents of an apartment 
complex) that will be managed by the unit brand partner. For example, in the case of an 

- 15- 



apartment complex, such required data elements may include the physical address of each 
building in the apartment complex and valid unit numbers for each building in the apartment 
complex. Brand partners 120 also set up facilitation provider access accounts for employees or 
representatives of the administrative brand partner and any subordinate brand partners. The setup 
5 of access accounts includes the generation of a unique user name and an associated password for 
each representative or employee. Such access accounts enable the employees or representatives 
to access facilitation provider 140 and to engage in the various setup, registration and 
maintenance activities associated with the use of facilitation provider 140 and its related 
functionality. 

y 10 [0070] Referring back to Figure 2, brand partners may make certain selections relating to their 

i : s 

customization 204 of the customer interface as part of the brand partner setup and registration 
IH process. In the preferred embodiment of the present invention, facilitation provider 140 contains 

in web-based applications that are executed by brand partners 120 to setup a customized web site 

for customer access. As one of ordinary skill in the art will appreciate, such web-based 
% 15 applications contain web site templates that allow customization of various elements of the 
u templates whereby a custom look and feel is created for each web site. The elements which may 

be customized by (or on behalf of) brand partners 120 may include, among others, web site 
colors, banners, images, general text, and fonts. This process is also referred to as "private 
labeling" of web sites. The private labeling process permits brand partners 120 to present a 
20 custom web site interface to their customers 110, while all of the functionality and computer 
applications which run behind the scenes are uniform standards provided by facilitation provider 
140. Therefore, brand partners do not have to develop, at great expense and time, their own 
Internet web-based applications to interface with facilitation provider 140. 
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[0071] Customers 110 may access the custom web site interface 141 on facilitation provider 
140 through links established in a separate brand provider web site, or customers 110 may 
directly access the Internet web site of facilitation provider 140. In each case the customer's 
unique user name and password will identify the particular unit brand partner under which the 
5 customer is registered. Thus, the appropriate custom web site features and selections will be 
displayed by facilitation provider 140 to the customer 110. 

[0072] The setup and registration process for brand partners 120 allows brand partners to make 
certain selections 206 regarding what service categories will be available to their customers 110 
and which service providers 130 may offer their goods and services to the customers 110 under 

10 each service category. In the preferred embodiment of the present invention, facilitation provider 
140 contains web-based applications that are executed by brand partners 120 to perform the 
service category configuration 206. As noted above in the discussion of Figure 3, the facilitation 
provider's database provides a list of all valid service categories and service providers that are 
available to all brand partners 120. Typically, each administrative brand partner decides what 

15 service categories will be available to each unit brand partner that is subordinate to the 
administrative brand partner. Once service category selections are made, the administrative brand 
partner may select which service providers will be available to the customer 110 for providing 
goods and services under each particular service category. Of course, this service category 
configuration may be left up to the unit brand partners. As previously defined, the range of 

20 service categories and the variety of service providers are unlimited. 

[0073] Once brand partners 120 have completed all of the necessary setup and registration 
procedures, unit brand partners enter into relationships with customers 110 (e.g. leases with 
residents). Upon entering into a relationship with a customer 110, unit brand partners access 
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web-based applications on facilitation provider 140 to perform customer registration 208. In 
order to register a customer 110, unit brand partners provide certain basic data elements to 
facilitation provider 140. Such data elements may, for example, include the customer's name, 
address and apartment number. Unit brand partners may provide other information relating to the 
5 customer 110, such as telephone numbers, email address, and other contact information. The 
facilitation provider 1 40 then creates a customer account for the newly registered customer 110 
by creating a new database record and generating a unique username and password for each new 
customer. The customer accounts enable the new customers to access the customer interface 141 
of facilitation provider 140. 

10 [0074] The computer implementation of the brand partner interface 143 is preferably 
accomplished by writing web-based applications in Java, using the Oracle relational data base 
management system. The data structures are preferably stored in Oracle relational databases. In 
the property-manager/tenant example, new brand partner accounts may be made in the form of 
new account records in the database 142. The account records might be given the data structure 

15 shown in Figures 4 and 5. In the same example, a new customer record might have the structure 
shown in Figure 6. These figures show data type definitions which specify the various data 
elements of a brand partner record and a customer record, and show the relationships between 
these data elements in a format that will be understood by one of ordinary skill in the art. Some 
of the data elements in the records will be populated with the information provided by the brand 

20 partner (e.g., resident's first, last and middle names, the apartment number, and service address), 
others may be populated or modified by the facilitation provider (e.g. credit information, default 
values for notification options), the customer (e.g., social security number, occupation, previous 
address), and/or the selected service providers (e.g., provider account information, primary home 
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phone number). The structure of the brand partner account record and customer account record 
may be customized by the facilitation provider for the particular application of the facilitation 
service. 

[0075] As one ordinary skill in the art will also appreciate, computer programs may be easily 
written to access the relational databases and produce reports 210 which will assist brand 
partners 1 20 and others in tracking and analyzing the various transactions and activities described 
above. 

[0076] Figure 7 shows various components of a preferred embodiment of customer interface 
141. Each of these components may be in the form of one or more web pages that the customer 
can access via the Internet to carry out the desired function, generally by entering data and 
observing the results of their actions. Customers 110 may access login page 400, select and 
compare service offerings page(s) 410, order services page 420, order status check page 430, 
terminate services page 440, update profile page 450 or generate reports page 460 via customer 
interface 141. 

[0077] As described above, brand partners 120 access facilitation provider 140 to set up access 
accounts for the customers. The brand partners then provide the customers with account 
usemames and passwords. Referring now to Figure 8, a screenshot for the login page 400 is 
shown. Customers 110 enter their assigned account usernames 510 and passwords 520 to gain 
access to their account information stored in facilitation provider 140. 

[0078] Referring now to Figure 9, customers begin the process of shopping for services 410 by 
selecting a desired service category 690. In the preferred embodiment, there may be two types of 
service categories 690: basic services 610 and additional services 620. Basic services 610 may 
include services such as electricity, local telephone, long-distance telephone and cable or satellite 

- 19- 



television. Additional services 620 include services such as high speed Internet access, bottled 
water delivery, renter's insurance, appliance rental, interstate movers, furniture rental, electronics 
rental, cellular phone, maid services, newspaper delivery, dry cleaning, local movers, health 
clubs, dial-up Internet access, self storage, security monitoring, grocery delivery, toll tags and 
5 restaurant delivery. Other basic services 610, additional services 620 and any other kind of 
service category may be easily added under the preferred embodiment. 

[0079] The list of service categories 690 is determined by selections previously made by brand 
partner 120, as described above in relation to brand partner interface 143. Customer 1 10 selects a 
service category 690, either from basic services 610 or additional services 620, and based on that 
10 selection, the customer is provided with a list of service providers 680. The list of service 
providers is preferably determined by a real-time search which identifies the offerings available 
to the customer based on the market that the customer is a part of, and based on service provider 
selections previously made by the brand partner 120. 

[0080] For illustrative purposes, Figure 9 demonstrates the selection of the "Cellular Phone" 
15 service category from the additional services list 620 and the corresponding listing of six service 
providers 680: PrimeCo, SBC, Excel, Houston Cellular, VeriZon, and WorldCom. In the 
preferred embodiment, customer 110 may select up to 3 service providers 680 to compare. Once 
the service providers 680 to be compared are selected, the customer initiates the compare process 
by pressing the compare button 660. Comparisons of selected service providers 680 are done 
20 based on the plans provided in the service offerings of the service providers. 

[0081] Referring now to Figures 9 and 10, if any one of the selected service providers 680 have 
more than one plan 710 in a service offering, then the customer 110 may be provided with the 
opportunity to select one or more of the plans 710 to be included in the comparison process. If 
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none of the selected service providers 680 have more than one plan in their service offerings, 
then the screen in Figure 10 is preferably not presented to customer 110. Once the foregoing 
selections have been made, customer 1 10 is provided with a comparison of plans offered by up to 
three service providers 680. 
5 [0082] Referring now to Figures 1, 9 and 11, selected service providers 680 in the selected 
service category 620 and selected service plans 810 are preferably listed in a tabular fashion to 
facilitate comparison by customer 110. The tabular listing also preferably includes packages 820 
and features 830 for comparison. All plans 810, packages 820 and features 830 include 
descriptions and prices. The tabular arrangement facilitates easy comparison by listing 

10 comparable line items horizontally along the same line. For example, the "LD/Min" charge (i.e., 
long-distance charge per minute of use) under the PrimeCo Calling Plan 812 is listed on the same 
line as the LD/Min charge under the PrimeCo NOW Plus Calling Plan 814. This makes it easy to 
quickly compare the two charges and to quickly and easily note that the former plan has an 
additional line item charge of 7 cents per minute for long distance while the latter plan does not 

15 charge for long distance (it is included in the overall price of the plan). 

[0083] Still referring to Figure 11(a), the line items under additional features 830 are 
standardized to facilitate comparison. Many service providers 680 have their own unique 
descriptions or trademarks for such additional features 830. To facilitate easy comparison, the 
preferred embodiment of the present invention converts the service providers' unique 

20 descriptions and trademarks for additional features 830 into standardized descriptions. This 
avoids confusion on the part of customer 1 1 0 by obviating the need for the customer to figure 
out, for example, what a particular cellular phone service provider calls its voice mail feature or 
its text messaging feature. Nevertheless, as shown in Figure 11(b), the service providers' 
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customized descriptions are preferably made available in a pop-up window when the customer 
clicks on the label for the standard feature. 

[0084] Referring now to Figures 1, 7 and 11(a), the customer selects any packages 820 or 
additional features 830 that he or she desires by clicking on selection boxes. Once all selections 
have been made, charges may be calculated automatically by selecting calculate charges 840. 
Alternatively, a change in the selections may dynamically regenerate pricing additional plans, 
packages, and/or features, and dynamically regenerate the indications of which features are 
, included or excluded from selected packages. Total charges are then compared and a decision is 
made by customer 110 whether to order services 420. This decision includes which plan and 
which service provider will be selected to provide the particular service. This selection is made 
by selecting the order 850 button corresponding to the selected service provider. 
[0085] To further assist customer 110 in his or her decision as to which service provider 680 
will be selected, a map may be provided at the top of this page for certain service categories (e.g. 
dry cleaners, self storage). The map preferably shows the physical proximity or locations of each 
service provider 680 relative to the customer's home address. This additional information may be 
beneficial in selecting a service provider when the relative proximity of the provider is a 
substantial factor in the decision-making process. For example, while the relative physical 
proximity of an Internet access service provider may not be a very important factor, the proximity 
of a dry cleaning service provider or a health club will likely be an important factor in the 
decision making process. 

[0086] Referring additionally to Figure 12, after customer 110 selects a particular plan 810 
from a service provider 680 using an order button 850, the customer is presented with a recap 
910 of his or her order for verification and confirmation. If the recap 910 is incorrect in any 
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manner or the customer changes his or her mind for any reason, the customer returns to the 
previous screen (Figure 11(a)) to make appropriate changes. Following the recap 910, the 
customer is prompted to enter payment information 920 and any other information which the 
service provider requests during the setup of the service offering. Advantageously, required 
elements that the customer has entered elsewhere may be pre-populated as default values to 
eliminate redundant data entry. Further, entry fields are displayed for only those elements which 
the individual service provider has chosen to require for that offering. Thus the customer is not 
subjected to entering unnecessary data. 

[0087] The information which the service provider has selected may include the custom data 
elements discussed above with respect to the process of setting up service offerings by service 
providers. Other information also includes, without limitation, customer contact information 
(telephone, facsimile, email address, other physical addresses, etc.), service start date, and 
appointment date and time. Once customer 110 verifies his or her order recap 910, provides all 
required payment information 920 and provides all other requested information, the customer 
selects the submit button icon 930 to continue processing the order. On the other hand, customer 
110 may elect to save his or her order information with facilitation provider 140 and return to it 
at a later time by selecting the save button 940. If customer 110 elects to submit his or her order, 
then the order is communicated by facilitation provider 140 (Fig. 1) to service provider 680 (Fig. 
9). Customer 110 may return to customer interface 141 to check the status of orders 430 (Fig. 7) 
at any time. The processing of the order by the service provider and its response to the customer 
via the facilitation provider is discussed below. 

[0088] With respect to date entry fields, the date data element may be defined by the service 
provider with certain restriction rules. For example, the service may define an appointment date 
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element which requires the customer to enter a date, but restricts the date to a weekday. Thus, 
dates that fall on a weekend might trigger an error message to the customer, explaining that the 
date must be a weekday. So one restriction rule is to restrict the date values to certain days of the 
week. Another restriction rule is to prohibit date values that correspond to specific holidays, e.g. 
5 Thanksgiving (a predetermined weekday), and Christmas (a predetermined date). Yet another 
useful restriction rule is to require a minimum lead time. That is, the date value must be some 
minimum number of days into the future. Some services may wish to run a credit check before 
the customer's first appointment, and this may require at most three days. Such services could 
specify a three-day lead time to guarantee that the credit check is completed before the 
10 appointment. Similarly, the service provider may wish to specify a maximum lead time to avoid 
accumulating orders in the distant future. Such orders may have a higher default rate, for 
example. These various date restriction rules may preferably be selected independently and 
jointly. 

[0089J It is noted that the above-described ordering process is facilitated by the design of the 
1 5 customer interface 141 . In particular, the process flow (i.e., the presentation of service categories, 
presentation of service providers, interactive comparison of offerings, and customized order 
information entry with population of default values for previously entered data field information) 
has been well received during concept testing. This interface design is made possible by a novel 
data structure contained in the facilitation provider software. This data structure is illustrated in 
20 Figure 32 (described further below). 

[0090] To further ease the burden on the customer 1 10, the facilitation provider 140 may detect 
order inter-dependencies and may offer to establish an order as a "dependent" order. This might 
occur where a phone number is required, and the customer's order for phone service has not yet 
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been fulfilled. For example, the facilitation provider may generate a "list box" to an entry field 
for a required data element. A user clicking on an arrow adjacent to the entry field is presented 
with a list of values which may be selected for automatic entry in the field. The facilitation 
provider may automatically detect existing orders that could produce the required data element, 
and present a dependence indicator (such as "to be provided by SW Bell") for each such order as 
a value in the list. Alternatively, if a required data element for an order is left blank, the customer 
interface 141 may check to see if an order has been placed that would provide the required data 
element. If such a dependency is detected, the interface offers to submit the order as a dependent 
order, that is, an order which will automatically be submitted by the facilitation provider 140 
when the outstanding order(s) have been fulfilled by the respective service provider(s). This 
behavior may preferably be allowed or disallowed by the service providers for individual entries 
in the order form. 

[0091] Figure 30 shows the processing of such orders. In block 3002, the customer interface 
141 places an order into a delivery queue (in database 142). In block 3004, a check is done to see 
if the order is a dependent Order. An order is dependent if it relies on data ("Target Data") 
obtained from the acceptance of another order ("Master Order"). In block 3006, those orders 
which are not dependent orders are processed, i.e. placed in form for delivery, and notification 
sent to the service provider. If the service provider acknowledges receipt of the order, then in 
block 308 the status of the order is marked as "Delivered". If the service provider fails to 
acknowledge receipt of the order within a predetermined time period, then in block 3010 the 
status of the order is marked "Fail". 

[0092] Returning to block 3004, if the order is a dependent order, then in block 3012, a check is 
made to determine if the Master Order has failed. If so, then in block 3010, the status of the 
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dependent order is marked "Fail". Otherwise, in block 3014, a check is made to see if the service 
provider has sent a response to the Master order. If not, the dependent order is returned to the 
queue 3002 for repeated consideration later (preferably a 30 minute delay). If so, then in block 
3016, a check is made to determine if the response includes the Target Data. If not, then in block 
5 3010, the dependent order is marked "Fail". If the response includes Target Data, then in block 
3006 the Target Data is extracted from the response, and the dependent order is processed. 
[0093] Referring now to Figures 1, 7, 9 and 13, customer 1 10 may terminate services 440 from 
service providers 130 by accessing a disconnect facility in interface 141. Customer 110 selects 
Disconnects 630 which presents the disconnect facility shown in Figure 13. All service accounts 

10 which have been initiated by customer 110 at facilitation provider 140 are listed under 
Disconnects from accounts 1010 initiated at facilitation provider. Customer 110 selects the 
desired account to disconnect and provides certain disconnect related information to facilitation 
provider 140 as requested by service provider 680. The disconnect information is then 
communicated by the facilitation provider to the service provider for processing. 

15 [0094] Customer 110 may also disconnect service accounts 440 that are not initiated 1020 at 
facilitation provider 140. Based on information about the customer's previous addresses, 
facilitation provider 140 presents a list of previous residence addresses 1025 of customer 110. 
Customer elects the particular residence address 1025 at which the account to be disconnected 
was originally initiated. The customer 110 may then select a service category. Based on these 

20 selections, customer 1 10 is presented with a list of service providers 130 in that service category 
for the selected address 1025. Customer 110 elects the particular service provider 130 with 
whom the service account was initiated. The, customer is then presented with a list of questions, 
as previously provided by the particular service provider 130 to facilitation provider 140, relating 
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to the service termination request. Customer completes the questionnaire and the service 
disconnection data is sent to the service provider 130 by facilitation provider 140. The status of 
any disconnect requests by customer 110 may be displayed under current disconnects 1030. 
Alternatively, they may be displayed in the customer account summary along with the status of 
other customer orders. 

[0095] Customers 1 10 maintain information relating to their profile 450 on facilitation provider 
140. In the preferred embodiment, customers view and update their profile 450 by selecting the 
"my profile" 695 which preferably presents customers with six categories of profile information. 
Referring now to Figure 14, customer 110 may preferably view and update the following six 
categories of information: general information 1110 (Figure 15 presents an example of one such 
update screen), billing addresses 1120, personal information 1130, identification information 
1 140, financial institution account information 1 150, and credit card information 1 160. All of the 
foregoing information is preferably maintained by customer 110, except customer's name and 
address information 1115 which preferably can only be updated by brand partner 120. 
[0096] As shown in Figure 15, the general information update screen preferably allows a 
customer to enter information such as prior address(es), contact information, and account 
preferences (e.g. email notification of changes in order status, etc.). The personal information 
may include such things as social security number, birth date, mother's maiden name, etc. The 
identification information may include such things as drivers license numbers, passport 
information, etc. The financial institution account information may include such things as 
checking account names and numbers. 

[0097] Referring to Figures 1 and 7, the present invention contemplates that customer 110 has 
the ability to produce various reports 460 relating to all of the transactions and activities covering 
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the use of the systems and methods covered by this invention. Referring additionally to Figures 
16 and 17, in the preferred embodiment of the present invention, the account summary report 640 
lists all of the service orders and disconnect orders initiated by customer 110. This account 
summary advantageously provides a single integrated display where customers can monitor the 
status of their orders from multiple service providers in multiple service categories. As one 
ordinary skill in the art will appreciate, other reports may be generated to provide a hard copy of 
any transaction or activity. 

[0098] As discussed above, customers 110 shop and compare services offered by service 
providers 130 via facilitation provider 140. Once customer 100 decides to place an order with a 
service provider 130, facilitation provider 140 may provide an electronic notification of the order 
to the service provider, or may simply queue the order for periodic retrieval by the service 
provider. Service provider 130 processes the order and may send an electronic response back to 
facilitation provider 140. Customer 1 10 may later access facilitation provider 140 to review any 
such response from the service provider. Service provider 130 may also contact customer 110 
directly via traditional mechanisms, such as in person, by telephone, or by mail, in response to a 
service order. 

[0099] Referring now to Figures 1 and 18, service providers 130 access facilitation provider 
140 to set up and register service offerings 2010. Offerings are herein defined in terms of plans, 
packages, features, and rules. A plan is a base set of products or services offered by a provider, 
e.g. "Basic Local Phone" or "Digital Cable". A package is a collection of additional features that 
may be purchased as a single unit, e.g. a "movie package" having several premium cable 
channels. A feature is an individual item that can be ordered in addition to a plan and/or package, 
e.g. individual premium channels, or "call waiting". A rule is a restriction on the combination of 
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plans, packages, and features that may be selected by a customer, e.g. two packages may be 
mutually exclusive, or a feature may only be available if a given package is selected. As the 
service provider specifies the plans, packages, features, and rules of an offering, the service 
provider also specifies prices associated with each offering component (plans, packages, 
features), and may further specify pricing rules that vary the associated prices based on what 
other components have been selected. 

[0100] The plan and package restriction rules are preferably limited to two types: exclusion, 
and available. In the description of each plan (package), the service provider is able to specify for 
each of the other plans and packages whether they are unavailable (i.e., excluded) if the subject 
plan (package) is selected, or whether they are available (i.e. so that both could be chosen if the 
customer desires). The feature restriction rules may be of the above types, but preferably may 
alternatively be of two other types: included, and optionally included. When describing a plan or 
package, the service provider may indicate that a feature is excluded, available, included (i.e. 
required), or optionally included. Here, optionally included is defined to mean that a 
predetermined number of features are included, and the customer can select those features from a 
list of the optionally included features. Generally, the predetermined number is less than the 
number of optionally included features, so the customer can pick and choose. 
[0101] Referring momentarily to Figures 10 and 11(a), the service or product (generally: 
"offering") from the service provider is shown represented in terms of plans, packages, and 
features. Figure 32 represents the internal structure of a preferred offering representation. Within 
an offering, service providers can define plans 3202, packages 3204, features 3206, custom items 
3208, and the relationships between them. Each of these may be represented by corresponding 
data records in a relational database. 
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[0102] Each plan 3202 can specify a list of included features and a list of features that are 
optionally available. A plan 3202 can further specify a list of available packages, packages 
selected by default, and required custom items. 

[0103] Each package 3204 can specify lists of available, included, optional, and excluded 
features. Optional features are used to define packages in which the customer is asked to choose 
some number of features from a defined set. Packages 3204 can additionally specify additional 
custom items that are required, and custom items that are not required. Each package 3204 can 
also specify other packages that are excluded; i.e., the customer will not be able to order two 
packages if one excludes the other. 

[0104] Each feature 3206 can specify a list of other features that are required and excluded. As 
with packages, a customer cannot select two features if one excludes the other. If one feature 
requires another, the customer is prevented from ordering that feature unless he also orders the 
required feature. Features 3208 can also specify custom items that are to be additionally included 
or excluded. 

[0105] Offerings also include Price Rules 3304 (Figure 33). When a customer places an order, 
the price 3306 of each package and feature is determined by examining the selected offering 
elements 3302 (i.e., the combination of Plan, Package(s) and Feature(s) selected). A Price Rule 
3304 establishes a Price 3306 to be used for the specified combination of Offering Elements 
3302 that exists in the order. The set of Price Rules 3304 for a Package or Feature is preferably 
ordered so that if multiple Price Rules apply to an order for that Package or Feature, the 'first 1 
applicable one is used. If there is no Price Rule applicable to an order, the Feature or Package 
'default* Price is used. 
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[0106] Attached Appendix "A" shows an example of the offering data structure in XML format 
and Appendix "B" provides an example of this data structure with populated data values. 
[0107] In the preferred embodiment of the present invention, each offering is associated with a 
market. The definition of the market in which a service provider makes its offerings available is a 
broad and flexible one. A market may be defined in terms of states, counties, zip codes, and 
individual properties. Figure 19(a) shows an illustrative screen which might be provided by the 
configuration portion 2010 of interface 144. A text entry field 1902 is provided for naming the 
market being defined. Another entry field 1904 is provided for selecting one of several possible 
statuses, such as "Open" to indicate that the market definition may be associated with an 
offering, or "Closed" to indicate that the market definition is not yet available for other purposes. 
[0108] Selecting one of the links 1906, 1908, 1910, 1912 allows the user to add states, 
counties, zip codes, and properties, respectively, to the coverage of the market. Selecting the state 
link 1906 allows the user to select from a list of states. Selecting county link 1908 allows the user 
to enter a list of counties. Selecting the zip code link 1910 allows the user to enter a list of zip 
codes. Selecting the property link 1912 takes the user to a search page such as the one shown in 
Figure 19(b), where the user can enter search criteria in entry fields 1920 and generate 1922 a list 
of properties with corresponding selection boxes 1924. The user can actuate the selection boxes 
next to the desired properties and click Save button 1930 to return to the previous screen (Figure 
19(a)). Similar Save buttons may exist within the state, county and zip code selection screens. 
[0109] For convenience, entry fields 1914 and 1916 may be provided for direct entry of zip 
code ranges. Finally, a Save button 1918 is provided to complete the market definition. Note that 
a market may include selections from the state selection page, the county selection page, the zip 
code selection page, and the property selection page. These selections are additive, i.e. the market 
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may include Texas, various neighboring counties in Oklahoma and Louisiana, and selected 
properties in Albuquerque. 

[0110] Note too that the more specific selections preferably dominate over the more general 
selections. If, in the above example, a second market is defined for New Mexico, a resident of 
5 one of the selected properties in Albuquerque would be in two conflicting markets. Because his 
property is specifically identified as part of the Texas market, the resident would be presented 
with the provider offerings in the Texas market. The markets are preferably exclusive, and hence, 
no two markets can have the same entry in a given column. 

[0111] In alternative embodiments, the number and type of the location size items can vary. 
10 Although the current discussion assumes that the location size options are states, counties, zip 

codes, and properties, other location size options may be preferred. Thus, e.g., markets could be 

specified with reference to one or more of: stellar system, planetary system, astronomical body, 

hemisphere, continent, country, region, state, county, city, zip code, property, floor, unit, etc.. 

[0112] The market definition information discussed above is stored in an Oracle relational 
15 database. When a customer selects a service category, facilitation provider 140 determines which 

service providers serve the market for that the customer. Figure 3 1 shows a flowchart of one such 

determination process, given an address and a service category. 

[0113] The process is a search over all providers contained in the facilitation provider's 
database. Each provider defines one or more markets, each of which contains one or more 
20 specific properties, zip codes, counties, and states. When attempting to match a provider to an 
address, the provider's markets are checked in the order of most specific to least specific. 
[0114] An iteration of the loop begins in block 3102 and terminates in either block 3106 
(provider does not serve address) or block 3120 (provider does serve address). In block 3104, a 
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check is made to determine if the service provider has an offering in the selected service 
category. If not, iteration terminates in block 3106. The facilitation provider's software then 
performs the next iteration of the loop with another service provider. 

[0115] If the service provider has an offering in the service category, then in block 3108, each 
5 of the providers markets is checked to see if one of them contains the exact property at the given 
address. If so, that market will be the one used for the determining the offering details of this 
service provider, and in block 3 1 1 8, a check is made to verify that the market is active. If so, the 
iteration terminates successfully at block 3120. If not, then the iteration terminates unsuccessfully 
at block 3106. In either case, the next iteration is performed for the next service provider. 

10 [0116] Returning to block 3 1 08, if the property is not found, then in block 3110, each market is 
checked to see if it contains the 9-digit zip code of the service location. If so, the matching 
market is used in block 3118. If not, the search continues by 5-digit zip code (block 3112), then 
county (block 3114), and state (block 3116), providing a matching market to block 3 1 1 8 as soon 
as one is found. If no matching market is found in block 3116, then the iteration terminates 

15 unsuccessfully in block 3106. After the completion of all loop iterations, the list of service 
providers compiled in block 3120 (those having a matching market) is then presented to the 
customer. 

[0117] Each service provider is preferably limited to one active offering per market. The 
service provider may have authored various offerings for each market, but these offerings 
20 preferably have a status value associated with them. Of the offerings, only one is allowed to have 
an "Active" status. Other status values may be "Draft", "To Be Active", and "Archived". To 
avoid having any downtime caused by mistakes, the service provider interface attempts to 
maintain an Active offering once one has been established. The service provider wishing to 
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replace the Active offering may simply designate one of his Draft offerings as "To Be Active". 
At the next available opportunity (or alternatively, at a time specified by the service provider), 
the facilitation provider will simultaneously designate the Active offering as Archived, and the 
To Be Active as Active. Of course, the service provider can also specifically Archive an Active 
5 offering, but this would only be done when the service provider wishes to discontinue any 
offering in that market for at least some time period. 

[0118] In an alternative embodiment, a two-database approach is used. The service provider's 
changes are made to a "staging" database, whereas the customer's interactions are with a separate 
"production" database. At periodic intervals, the service provider's changes are migrated 

10 (copied) to the production database. 

[0119] In yet another alternative embodiment, each offering has associated with it one or more 
date ranges specifying when the offering is active. Each day, the facilitation provider's system 
determines which offering is active for each market by examining the date ranges. If the current 
date is within the data ranges for more than one offering, the offering with the most recent start 

1 5 date is designated as the active offering. 

[0120] Each offering must have at least one service plan. It is not unusual for an offering to 
have multiple plans. However, there may be zero or one or more packages and features in each 
offering. 

[0121] Relational database records are preferably created for the various service categories and 
20 service provider within each category. These records may, for example, take on the structure 
shown in Figure 20. Figure 20 uses the data type definition (DTD) format previously mentioned 
in relation to Figures 4, 5 and 6. 
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[0122] As part of the setup and registration process for service offerings 2010, service 
providers 130 provide detailed information regarding utilities, products, services and anything 
else that may be offered to customers 1 10 by the service providers. In the preferred embodiment 
of the present invention, service providers 130 provide details such as prices, descriptions, 
5 features, packages, internal codes used by service providers for features and packages, acceptable 
payment methods, billing methods, standard legal terms and conditions, and physical locations of 
service providers. A service provider may request that any customer selecting its service be 
required to provide to the service provider certain custom data elements. 

[0123] Custom data elements requested by service providers are generally specific to the 
10 particular service provided by the service provider. For example, a pet grooming service may 
p request custom data elements which include pet's name, pet's date of birth, and pet breed. An 

Ln Internet access service provider may request the customer's chosen username and password. 

y 1 Custom data elements are implemented in the preferred embodiment of the present invention by 

£ 1 .'. J^h . 

asking the service provider to provide certain information regarding each custom data element. 
15 15 [0124] As an illustration, the pet grooming service in the previous example may ask for a pet's 

name to be a custom data element that is completed by a customer requesting a pet grooming 
service. In order to implement this custom data element, the service provider provides the 
following information about the custom data element to the facilitation provider: custom data 
element name, element identification code, element data type, display text, long description, 
20 image, and criticality. The service provider's response to each of the foregoing fields might be: 
"pet_name," "PN01," "generic text," "What is your pet's name," "Please enter the name of your 
pet in the field provided," "nametag.gif \ "optional". 
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[0125] The custom data element name "pet_name" may represent the name of the custom field 
in the service provider's internal computer system. The element identification code "PN01" may 
be a code that is only meaningful to the service provider's internal computer system once the 
order is received from the facilitation provider. The element data type "generic text" is a 
selection made by the service provider to indicate what data type the service provider is 
expecting to receive from the facilitation provider. This information permits the facilitation 
provider to display the appropriate data entry interface to the customer, e.g. a text entry field in 
this case. The data types available for selection by the service provider for custom data elements 
may include data types such as boolean, generic text, list, date, telephone, address, provider 
location, and label. A phone data type might cause the facilitation provider to provide an entry 
field and also provide a pop-up list of previously entered phone numbers associated with the 
customer. Of course, other data types may be provided, and service provider customization of 
data types may be further enhanced. 

[0126] The display text "What is your pet's name" tells the facilitation provider what the 
customer will see when this custom data element is presented to the customer for data entry. The 
long description "Please enter the name of your pet in the field provided" may be used by the 
facilitation provider to provide further clarification to the customer in the event the customer is 
unclear what the display text is asking for. The long description may be useful in implementing 
the well-known tool-tips technology in programming user interfaces on a computer screen. The 
image field, provides the service provider the opportunity to include an image to go along with 
the requested custom data element. In this above example the service provider chooses to provide 
an image of a pet name tag. The provider could also choose not to provide an image. Finally, the 
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"optional" criticality indicates that the customer does not have to enter a pet name in order to 
place the order, i.e. it is not required. 

[0127] In the preferred embodiment of the present invention, and as one of ordinary skill in the 
art will appreciate, the above described service offering setup process 2010 is implemented based 
on applications using the Java programming language on facilitation provider 140. Various user 
interface screens are written to collect the information contained in each service offering. The 
data structure used to collect and store the details of each service offering 2010 is preferably 
maintained using the well-known XML document format. The XML document is preferably 
stored in an Oracle relational database. 

[0128] Attached Appendix "A" provides an XML document format that may be used to define 
data elements used for specifying service provider offerings. Attached Appendix "B" provides a 
sample XML document with data values for the defined data elements. These data values may be 
entered via a graphical user interface (GUI) authored in the Java programming language using 
techniques and tools well known to those of ordinary skill in the art. 

[0129] In addition to specifying their offerings, service providers can specify their order 
delivery preferences 2020. The various options may include notification only 2022, email with a 
link 2024, and real-time integration 2026. A given service provider may not be able to select 
from all of these options. Certain service categories may only be offered the notification option. 
Conversely, certain service providers may not have the infrastructure to support real-time 
integration. Each of these options is discussed in turn. 

[0130] Order notification 2022 may be accomplished via the transmission of a facsimile or 
"non-secure" email to the service provider 130, where the order information is processed 
manually using the service provider's existing order process. The order notification may simply 
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include the customer's name and contact information, along with the custom data elements 
specified by the service provider. This would enable the service provider to directly contact the 
customer and collect any other necessary information. This option 2022 may generally be a one- 
way communication from the facilitation provider to service provider 130, and consequently, the 
5 service provider would typically not send any response to the facilitation provider 140. This 
option might be particularly suitable for communicating with a technologically unsophisticated 
service provider 130, or where the service provider may not have the technical and/or other 
financial resources to put in place a computerized order processing system. A service provider 
130 in such a scenario need only have access to a facsimile machine or the ability to pick up 

10 email messages from the Internet, in order to receive orders from facilitation provider 140. 

[0131] Still referring to Figure 18, in the email with an order URL 2024 notification option, 
service provider 130 receives an email containing a URL (uniform resource locator) link to a 
computer file which contains the details of order 420. Figure 21 illustrates a sample email with 
an order URL 2024. The computer file containing order 420 may exist in one of many different 

1 5 formats, including, without limitation, HTML format, XML format, plain text format, or comma 
delimited format. Preferably, the file exists in XML format and may be converted to any other 
format based on the service provider 1 selections during service offering setup 2010. Service 
provider 130 receives the order file in their selected format. Typically, under this order 
communication method, the service provider clicks on URL link 2110 and a human 

20 representative enters the assigned username and password to gain secure access to the fulfillment 
portion 2030 of the service provider interface 144. 

[0132] For illustrative purposes, Figure 22 shows a hypothetical order as it might be displayed 
by service provider interface 144. After gaining access to the facilitation provider 140, the human 
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representative may then read the order 420 information and manually re-type (or cut and paste) 
the order 420 data into the service provider's legacy or internal order processing system. 
Alternatively, the URL link may lead the service provider's representative to a web based 
application that allows the service provider to download the order data in a file format designated 
5 by the service provider. Once the service provider's legacy or internal system completes 
processing the order, the service provider generates a response 2210 with its approval, denial, or 
other action (e.g. a request for additional information) of the received order 420. 
[0133] Figure 23 illustrates a sample response screen that might be used by the service provider 
130 to respond to customer 110. Various entry fields may be provided for entry of the customer's 
10 new service account information (for example), or for entry of reasons for denial. This 
information is transmitted to the service provider 130 and added to the customer's account 
record. Customer 110 may then view the service provider's response through the customer 
interface 141. 

[0134] In the real-time integration 2026 communication method, service provider 130 
15 preferably retrieves orders 420 from facilitation provider 140 using a fully automated process 
(i.e., with little or no human intervention), and automatically enters the order information into the 
service provider's database or other electronic order processing system. Under the preferred 
implementation of this option, service provider 130 periodically polls facilitation provider 140, 
using HTTPS (secure hyper text transfer protocol) requests to check for queued orders. Of course 
20 other protocols may be employed, e.g. FTP (file transfer protocol), HTTP (hyper text transfer 
protocol), and other file handler protocols which support data transport. As one of ordinary skill 
in the art will appreciate, service provider's polling of facilitation provider 140 may preferably be 
accomplished by use of standard API's (application programming interfaces). 
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[0135] The fully automated process may be facilitated through the use of an adapter layer 
(identified as communicator application 134 in Figure 1). The adapter layer is a software 
application that interfaces between the service providers' legacy internal order processing 
systems and databases, and the facilitation provider's software and databases containing the 
5 customer orders. Because each service provider 130 has its own internal order processing system, 
each service provider has its own, potentially unique, requirements for data formatting and 
communication protocol. The adapter layer acts as a liaison. In this architecture, the facilitation 
provider's core applications and databases need not be modified to work with each service 
provider's legacy system. Instead, the adapter layer intercepts each service provider's request for 

10 orders (or proactively initiates requests to supply the service providers order queue) and converts 
the request and order formats to enable communication between the service provider's internal 
systems and the facilitation provider. Requests are converted to a form understandable by 
facilitation provider's order databases and applications. Similarly, responses (orders) from 
facilitation provider are intercepted and converted into a format understandable by the service 

15 providers' legacy system. 

[0136] In a preferred implementation, communicator 134 is a pure Java data-exchange software 
application. It may take order data in XML format from the facilitation provider 140 and 
transform order data into a service provider specific format (e.g., XML, HTML, delimited file, 
fixed file, named pair file, or database table). Similarly, communicator 134 allows the service 

20 provider 130 to provide responses to the facilitation provider 140. The response can originate 
from many different service provider file formats (delimited, fixed, XML, etc.). The commu- 
nicator 134 translates the service provider response file into a valid XML response. 
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[0137] The communicator 134 is preferably a multi-threaded application. That is, it performs 
various tasks in parallel. In particular, the communicator 134 may preferably be split into 
receiving and responding portions that run independently. 

[0138] As shown in Figure 24, the communicator 134 takes a typical order through the 
5 following stages. In block 3202, the communicator 134 polls each specified service category to 
retrieve a list of orders in that category intended for service provider 130. In block 3204, the 
communicator 1 34 proceeds through the list, individually retrieving the details of each order 
from the facilitation provider 140 and preparing the order for translation into the specific service 
provider format. In block 3206, one or more software modules are invoked to convert the data 
■!f 10 from XML format to the service provider format, and to convey the order to the service 
q provider's internal order processing system. Note that the communicator may be configured to 

: * 
: : : 

iH translate into multiple formats and to send the file to multiple systems if desired. In block 3208, 

the service provider processes the order and generates data for a response. This response data 
H may be dropped off in an "outbox", i.e. a file directory or other form of data container. In block 

*2 15 3210, the communicator invokes another software module to translate the response data into the 
u appropriate XML format used by the facilitation provider, and to convey the translated response 

to the facilitation provider. The communicator preferably runs on the service provider's site and 
communicates with the facilitation provider via the Internet using a secure protocol such as https. 
[0139] Figure 25 shows the various software components of a preferred embodiment of the 
20 communicator 134. These include a retrieval process 3302, a library of translation modules 3304, 
a response process 3306, a monitoring process 3308, and an update process 3310. We turn first to 
a detailed description of the interaction of 3302, 3304 and 3306, and postpone describing the 
monitoring process and update process until afterward. 
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[0140] Referring now to Figure 26, the one specific implementation of the real-time integration 
2040 communication method between facilitation provider 140 and service providers' 130 legacy 
systems 2418 and 2420 is illustrated. Internal Communicator Engine (ICE) 2416 is a pure, 
independent, data exchange software application. Communicator 1 34 preferably retrieves XML 
order files from facilitation provider 140 and transforms the order files into a service-provider- 
specific file format (e.g., XML, HTML, delimited file, fixed file, named pair file, database table). 
It preferably allows for the service provider 130 to respond back to the facilitation provider 140. 
The response may be provided to communicator 134 in a service-provider-specific file format 
and translated by ICE 2416 into the preferred XML response format. 

[0141] As shown in Figure 26, an order may typically go through the following stages. ICE 
2416 periodically polls the facilitation provider 140 asking for all the orders for the service 
provider in one service category. The polling rate is preferably configurable by service category. 
The facilitation provider 140 responds with a list of orders, preferably using the HTTPS protocol. 
The list may be empty if no orders are currently . awaiting delivery. The ICE 2416 preferably 
merges the list of orders into an internal database. 

[0142] For each order, the communicator 134 calls XML handlers 2410 and 2412 to obtain the 
order details. XML handler 2410 sends an order ID and service provider information to 
facilitation provider 140. The response from facilitation provider 140 is an XML file. In the 
preferred embodiment, one XML file is created for each order. Handler 2410 converts the file 
into the service provider specific format. It does this through the use of an XML mapping 
language specified in the form of a script file. Advantageously, the alteration of a script file does 
not require a recompilation of the communicator. 
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[0143] Figure 36 shows a class definition diagram of handler 2410. Handler 2410 takes a script 
file that specifies a map (XSL or XMLDBMS map) and a file containing the order information 
(XML). The order information file is read into memory in a tree-like structure, with each node of 
the tree containing one element from the information file. The script file is then processed in 
5 order, with the element specified by the script file being located in the tree and written to an 
output file in order in the specified format. Appendix D and Appendix E are two examples of a 
script file. The script file in Appendix D provides for an XML representation of a semicolon- 
delimited file transformed to the facilitation provider's XML format. The script file in Appendix 
E provides for the transformation from an XML file to a database data file (such as would be 

1 0 provided as an input to handler 24 1 2). 

[0144] Handler 2412 takes the service-provider-specific format and provides any support 
commands needed to add the order to the service provider's database software (e.g., SQL 7.0, 
Oracle, Informix). Handler 2412 also uses a script file to map from a data file to a database 
record. An example of a script file of this type is shown in Appendix F. 

15 [0145] The working area set aside for handlers 2410 and 2412 is the receiving/staging area 
2414. ICE 2416 sends the completed results from this area to one or more designated destinations 
2418, 2420 specified by the service provider. Note that at the service provider's option, there 
may be multiple destinations, and that each destination may be provided a different file format. 
This might prove useful where the service provider has incompatible systems (e.g., an order 

20 fulfillment system and a billing system) that each need to be updated to reflect a new account. 
Figures 27(a) and 27(b) are flowcharts that of one embodiment of this process. 
[0146] The service provider's legacy system 130 processes the order and generates an 
automated response which is written to response staging area 2422. ICE 2416 will detect the 
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presence of the response in the staging area, and invoke handlers 2424 and 2426 to communicate 
the response to facilitation provider 140. Handler 2424 converts the response from the service- 
provider-specific format into an XML format that can be understood by facilitation provider 140. 
Handler 2426 delivers the XML file to the facilitation provider to notify facilitation provider 140 
5 that order processing is complete for the particular request. Figure 28 is a flowchart illustrating 
the function of handler 2426. Any errors in the generation and deliver of the XML response are 
trapped and an email is sent to service provider 130 detailing the detected errors. 
[0147] Both internal and external to facilitation provider 140, the messaging language is 
preferably XML. This includes internal communications (objects to objects) and external 

10 communications (server to server). The liaison software may preferably be XML-DBMS for 
transferring data between XML documents and relational databases. It views the XML document 
as a tree of data-specific objects in which element types are generally viewed as classes and 
attributes and PCDATA as properties of those classes. It then uses an object-relational mapping 
to map these objects to the database. An XML-based mapping language is used to define the 

1 5 view and map it to the database. XML-DBMS is publicly available both as a set of Java packages 
and as a PERL module. For more information about XML-DBMS, visit the XML-DBMS home 
page at: "www.rpbourret.com/xmldbms/index.htm". 

[0148] Monitoring process 3308 (Figure 25) allows a service provider representative to monitor 
and control the retrieval process 3302 and/or the response process 3306. It is designed to make 
20 the management of all the various data exchanges easier. The brand partner can get a quick 
summary of all the active data exchanges (services) and whether each service is receiving or 
responding. This makes the job of administering the exchanges significantly easier and different 
than most data exchange software. 

c 

-44- 



[0149] The process of using the console is simple. Each data exchange gets a separate window 
on the desktop. Inside that window there are five tabs: a receiving tab, a responding tab, a config- 
uration tab, a log history tab, and a request viewer. When these tabs are taken as a whole they 
describe the full life cycle of data integration. Each data exchange is treated as a separate service 
5 (its receiving and responding mechanism run in separate threads from, other services). Within 
these service windows, changes can be made dynamically through the configuration tab again 
increasing the ease of use for the administrator. Figure 35 shows a class definition diagram for a 
Java implementation of the logging utility and console. 

[0150] The universal console offers a tremendous amount of flexibility to the administrator. For 
10 instance, if data is currently being sent to the order entry application in a delimited format and 
they need to add another delimited exchange for the accounting system, the administrator can 
simply add an additional target or could even copy the service and create another service so the 
data exchange could be monitored separately. 

[0151] The monitoring process provides an interface that allows the representative to configure 
15 the processes, run multiple instances of the processes, start and stop each of the running 
processes, view the status of orders, and view an event log. The configuration may include 
setting such parameters as the identity and password of the service provider, selecting the service 
category, selecting a service provider format, setting polling frequencies, and specifying 
directories for incoming information, outgoing information, and intermediate work files. The 
20 user may wish to run separate retrieval processes for retrieving orders in each of several service 
categories, and may also wish to run respective response processes. The activities of each of the 
processes is preferably visible within one instance of the monitoring process, and multiple 
monitoring processes are preferably allowed. Each active process may preferably be individually 
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suspended and re-awakened. The communication status of orders, i.e. requested, received, 
pending, completed, may be viewed in the monitoring process interface. Finally, an event log 
may be viewed for troubleshooting purposes. 

[0152] Update process 3310 (Figure 25) offers service providers an easy and flexible way of 
updating the communicator application 1 34, and more importantly, their specific provider files. 
Changes are inherent in every system, e.g., changes in the provider's data storage mechanism for 
order processing. The update utility allows them to download provider-specific files that will 
reflect their data storage modifications, and makes them functional instantly. 
[0153] Referring now to Figure 29, the update process 3310 is illustrated. In block 2902, the 
communicator contacts facilitation provider 140 and downloads a specified master XML update 
file for that service provider. In block 2904 the update communicator parses the XML update 
file. In block 2906, the communicator filters through all the major and minor builds and presents 
to the service provider representative the updates that are compatible with the service provider's 
system. In block 2908, the representative makes a selection which can either be updating the 
entire application, or more commonly, updating selected provider files. If the service provider 
chooses to update the entire application, then in block 2910, the corresponding binary files are 
downloaded from the service provider, the communicator application is shut down in block 2912. 
[0154] More commonly though, the service provider wants to update specific provider files. 
After the representative chooses a build number, the communicator downloads and parses (2916) 
the specific XML file that contains all the needed information to update the provider files. In 
block 2918, the communicator shuts down service processes if needed. In block 2920, the 
communicator sets all local configuration properties first and all global configuration properties 
next. After all configuration properties are set successfully, the communicator in block 2922 
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downloads every file specified by the XML file from the facilitation provider and saves it on the 
service provider's system. Finally, in block 2924, the communicator restarts the service if a 
shutdown was performed. In any case of an error, whether from setting global/local configur- 
ations, or from downloading files, the communicator rolls back updates in block 2926 and 
5 restores the system to what it was prior to the update. Then, a restart of a service is performed in 
block 2924., 

[0155] Figure 34 shows a diagram of a preferred architecture for the communicator 134. The 
communicator preferably includes a Graphical User Interface (GUI), an Internal Processing 
Engine (IPE), and an External Connection Component (ECL). The GUI may include a multi- 

10 service desktop component, an integrated help component, a configuration component (for 
configuring operation of the communicator), a log component, an order management component, 
and a customization component (for customizing the appearance of the GUI). The IPE preferably 
includes a database handling component, a security component, a delivery component, a utility 
component, a log handling component, an event notification component, a secure 

15 communications component, a general file handling component, a disk caching component, a 
parsing component, a file backup component, and a scheduling component. The ECL may 
include a receiving system and a responding system. The receiving system may include various 
communication protocol handlers (HTTPS, FTP, HTTP, TCP/IP, etc.) and various transform 
handlers (RDBMS & JDBC adapters, XML, ASCII, HTML, etc.). The responding system may 

20 similarly include various transform handlers. 

[0156] It is emphasized that the communicator application 134 may have separate utility 
outside the facilitation provider model. The communicator advantageously has wide applicability 
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as a stand-alone translation and communication application with easily customizable translation 
scripts. 

[0157] The preferred embodiment of the present invention is developed using the following 
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Java programming language, Java Development Kit (JDK), version 1.1.8 from 
Sun Microsystems. 

JDK versions 1 .2.2 and 1 .3 from Sun Microsystems. 
XALAN version 2.0 from Apache 
XERXES version 2.0 from Apache 
JSSE version 1 .0.2 from Sun Microsystems. 
JAXP version 1 .0. 1 from Sun Microsystems. 
XMLDBMS version 1 .0 by Ronald Bourret. 
UNA2000 version 3.0 by I-Net Software. 
Applet Designer version 3.0 by Diamondedge. 
InstantDB version 3.2.1 by Lutris Technologies, Inc. 
WebObjects, Version 4.5, Apple Computer, Inc. 

Oracle Relational Database Management System, Version 8i, from Oracle Corp. 

SonicMQ, Version 2000.1, Progress Software Corp. 

FrontBase, Version 1 .27, FrontBase, Inc. 

MapQuest, Version 1.5.2, MapQuest.com, Inc. 

Apache Server, Version 1.3, Apache Software Foundation. 

JDOM, Beta Version 4, jdom.org. 

JMagick and ImageMagick, Version 5.2.1, Eric Yeo. 

Log4J, Version 0.9.0. 

GNU Regular Expression Package, Version 1.0.8. 
OpenSSL, Version 0.95a. 
ModSSLi Version 2.6.6. 

Adobe Photoshop, Version 5.5, Adobe Systems, Inc. 

ReportMill, Version 4.0, ReportMill Software, Inc. 

MPW Foundation and XMLKit, August 2000 Release, Metaobject GmbH. 

DashoPro, Version 2.0, preEmtive Solutions, Inc. 

TogetherJ, Version 4.2, TogetherSoft Corporation. 



[0158] Any of the foregoing embodiments of the present invention may be implemented by 
35 programming a suitable general-purpose machine having appropriate hardware. The machine 

may comprise a single computer. Alternatively, the machine may comprise a plurality of 



computers connected by a communications link. 
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[0159] The programming may be accomplished through the use of a program storage device 
readable by the machine and encoding a program of instructions executable by the machine for 
performing the operations described above. The program of instructions may be "object code," 
i.e., in binary form that is executable more-or-less directly by the computer; in "source code" that 
requires compilation or interpretation before execution; or in some intermediate form such as 
partially compiled code. The precise forms of the program storage device and of the encoding of 
instructions is immaterial. 

[0160] It will be appreciated by those of ordinary skill having the benefit of this disclosure that 
the illustrative embodiments described above are capable of numerous variations without 
departing from the scope and spirit of the invention. Accordingly, the exclusive rights sought to 
be patented are as described in the claims below. 

APPENDICES 

[0161] Appendix "A" provides an XML document format that may be used to define data 
elements used for specifying service provider offerings. 

[0162] Appendix "B" provides a sample XML document with data values for the defined data 
elements. 

[0163] Appendix "C" illustrates the format of the . XML documents exchanged between service 
provider 130 in response and facilitation provider 140 to communicate and fulfill a customer 
order request. Each response includes a fixed set of data, and may include additional information 
provided by the individual service provider. 

[0164] Appendix "D" provides an example of a script file for transforming an XML 
representation of a semicolon-delimited file to an XML file. 
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[0165] Appendix "E" provides an example of a script file for transforming an XML file into a 
database data file. 

[0166] Appendix "F" provides an example of a script file for mapping elements of a database 
data file into a database record. 
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